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simulate a negotiation, to generate a Pareto-optimal agreement or to identify which 
terms and inputs are significant to a Pareto-optimal analysis. 

In fact, the INSS article makes it quite clear that the values assigned to terms (called 
Options (values) and issues (similar to terms) in INSS) are irrelevant to its Pareto 
"analysis". While sounding complex, a Pareto-optimal agreement is nothing more than 
one which could not be improved for one party without making it worse for the other. 
Historically, negotiation support systems (NSS) might have attempted to perform an 
objective analysis of the values of the terms in an agreement to determine this. That is, 
they jnight have tried to find an agreement say, with better price terms for both parties 
than the one they agreed upon. This could be useful if price is the most important 
factor for both parties. However, it is often the case that objective measures such as 
price or delivery times are not as important to the parties as other, more subjective 
factors. 

Thus some modem NSS systems typically do not attempt objective analysis of terms at 
all. Instead, they rely solely, as INSS expressly does (as will be seen below), on 

subjective ratings which the users supply. Thus it is irrelevant which agreement might 

1.-. 

'^objectively" be better or optimal for both parties. It is also irrelevant which terms are 
significant for Pareto optimality for two reasons. First INSS doesn't analyze the terms 
(issues and options in INSS), for Pareto analysis — it only looks at ratings. Second, the 
users of INSS are asked to rate all the terms and combinations and values — thus no one 
term {issue) or value (option) is more significant than another — all get ratings. As will 
be seen, this makes the computation of Pareto-optimality a simple arithmetic problem 
of comparing ratings that does not require analyzing terms (issues and options) at all. 
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"There are only two issues in this simple negotiation: the price of the aircraf t and the 
teWof the warranty. It has been established that the normal price ofthis aircraft is in 
the range of $300,000 to $320,000. The sensible increase is of $10,000. Thus, the pnee 
options are $300,000, $310,000, and $320,000. In this industry there are four types of 
warranty typically available. The options are: no warranty, a 6 month, one year, and a 2 
year warranty. 

R>W: negotiators analyze the two issues and their associated options in terms of their 
relevance to their respective organizations and move to the pre-neeotiation phase- 
[Underlining emphasis added.] 

As the rest of this example shows, all the possible terms and ajl the possible values 
(issues and options in INSS terminology) of this negotiation are already in the model as 
subcombination of the two issues (terms) with their respective options (values). 



In th& aircraft example, from the INSS article there would be 12 possible sets of issues 
and options that would make up an aircraft model: 
AIRCRAFT MODEL: 



: Package No. 


Issue 1 


Issue 2 


l : 


$300,000 


0 


2 : 


$300,000 


6 mos. 


3 : 


$300,000 


1 yr 


:4 : 


$300,000 


2yr 


:5 : 


$310,000 


0 


6 


$310,000 


6 mos. 


7 


$310,000 


1 yr 


8 : 


$310,000 


2yr 


9 


$320,000 


0 


.10-: 


$320,000 


6 mos. 


11 


$320,000 


lyr 


: 121; 


$320,000 


2yr 


* Ratings marked with an asterisk are h 



Maki's rating 

30* 

15* 

20* 

0* 

50* 

40* 

30* 

25* 

100 

75 

90 

60 



Suny's rating 

70* 

80* 

100* 

90* 

40* 

50* 

60* 

30* 

0* 

20* 

15* 

10* 

from the INSS article. 



Again, in the glossary at Page 20, a package is defined as 

''A particular combination of options that has been selected across all the issugs.. For 





3000$ 


Payment 


Upon Delivery 


Faihire rate 


5% 
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thus it can be seen that for each case used for the mock negotiations using the TNSS 
simulation system, all the variafrlqs are known ahead of time and inserted into the case 
or model bv issue name and option value prior to any muck negotiation. For die 
aircraft model, issue (term) one can have three options (values)— $300,000, $310,000 or 
$320,000. Issue (term) 2 can have four options (values): 0, 6 months, 1 year or 2 years. 
The Combination of three options (values) for issue 1 and four options (values) for issue 
2 results in 12 possible outcomes or packages, as seen above. They can be stored in the 
computer in a simple table similar to aircraft model shown above, or in similar 
arrangements in a file. Not only is there no disclosure of analysis by the TNSS simulator 
tb understand the purpose of the terms in the INSS article, there is no need or 
requirement for analysis to understand the purpose of the terms, or in the case of INSS, 
the ifiisues, since all of their possible values (options) must already be known ahead of 
time by the simulator. 

Ih the two examples cited in the TNSS article, it does not matter whether the name of 
issue 1 in case 1 is annual salary or as in the aircraft model, issue 1 is named price. What 
matters is that all the possible options or values for that issue number are specified 
ahead of time so the case can be built. The simulator neither knows nor cares that it is 
simulating a price negotiation as opposed to a salary negotiation. It does not analyze 
terms or need to analyze them, during a mock negotiation, since they are predefined in 
the Model as issues and options. All that is needed for the INSS simulator to operate is a 
4et ci pre-defined issues (terms) and options (values). 
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This pre-definition is made even clearer on Page 17, where the INSS article states, under 

the feadrng "INSS FAQ (Frequently Asked Questions)", question no, 2: 

"2. 1 have requested a negotiation already. When can I start my negotiation? 
Your^negotiation will be set up typically within 2-3 days. INSS will notify you via e- 
riiaili ^(specifying your negotiation name and user name), after which you can start your 
negotiation right away/' 

The Set up mentioned here refers back to Page 6, "Describe a new negotiation case, 
where the article states, "You can request that a new negotiation case be set up for you 
by submitting this form/' 

Neither of the players who use the INSS simulator for a mock negotiation supply the 
values (options) for the issues during their mock negotiations. These values have 
already been programmed into the case they are using before the mock negotiation 
begins. In fact, unless one of the players is the one who requested that the case be 
constructed, neither of the players provides any input at all for "terms" (issues and 
their options) when he or she uses the INSS simulator. 

FageS, for example, shows the aircraft case which has been set up by the authors to 
show how to use INSS. In this example, players "Maki" and "Suny" do not supply any 
of the options for issues 1 and 2. Since the "terms" (issues) and all possible values 
(options) they can have are pre-programmed into a case before a mock negotiation can 
begiii/ there is no need for, and no disclosure of any analysis done by the INSS 
simulator to understand the purpose of the terms (issues). Unlike applicants' invention, 
which analyzes terms during iterations of a negotiation to understand their purpose, it 
is irrelevant to the INSS simulator whether an "issue" is a price term or a warranty term 
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oria salary term or a vacation term. INSS only deals with predefined options for named 
issues as these are stored in the model. 

Nor is^there any disclosure of which terms (issues) relate to which party either before 
mocknegofaation begins or during it The values (options) for all the terms (issues) are 
supplied in advance hy ogmon who creates th e case, not by the parties during a 
mockjnegotiaHon. Since the person who builds the case need not be, and, more 
frequently, is not likely to be-, either of the players who use the simulation case, it is 
clear ^at INSS also does not relate the terms (issues) to either player. In the aircraft case 
example, all the values (options) for all the terms (issues) have been supplied in 
advance by the authors, to show how to use INSS. There is no way in which INSS can 
nkat£ any of the price ($320,000) or warranty (2 years) option values to player "Maki" 
ot "Suny", since neither player supplied them. Therefore, the rejection is also incorrect 
in stating that INSS must identify which terms (issues) relate to which party. 

What; the players do supply are subjective ratings for the issues and values, but this, 
too, is done before any mock negotiation can begin and in such a way that the simulator 
does not provide any analysis. 

At page 2, for example, under the heading "Using INSS" it states: 

Theffe are three basic steps that are usually followed in any negotiation: 
Preparation for the negotiation, during which you study the situation, identify the 
stakeholders, and develop o very clear understanding of the issues and [interests 
involved. To help you do this step, INSS provides you with a detailed description ot 
your?negouation case and then guides you through a sequence of pages on which you 
tell the system how important ea c h issue and alternative is to V^J^f^P 'V™? 
^11^ nreferencp flliritation. The information * o obtained is used by INSS in the neyt 
Iterrttt ffive vot. helpful feedWV when co ^ h-^rKng new offers or evaluating your 
Counterpart's offers ." [Underlining emphasis added] 
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Again, this information about how each player rates the data is collected frefaye a mock 
negotiation begins. At Pages 8 and 9, under the headings "Using 1NS3: An Example", 
and Preparation", the article describes three types of ratings the players are asked to 
do: Issue rating, Option rating and package evaluation, 



Iii the example on page 8, of the aircraft case, the players Maki and Suny are first asked 
to rate the two issues* As the article notes : 

"Maki feels that price is far more important than warranty. Therefore, she assigns 70 
points to price and 30 to payment {sic — this presumably should have been warranty}. 
Although Maki does not know it, Suny feels that each issue is equally important and so 
Suny assigns 50 points to each/' 

On P&ge 9, under the heading Option rating, it is stated: 

"After rating the issues, the options in each issue must also be rated similarly. In the 
INSS jsystem, for each issue at least one option must be assigned the maximum rating 
for life issue and at least one option must be assigned a rating of zero / 7 [Emphasis 
added.] 

Note that this makes it even dearer that all the values (options) for the variables of a 
negotiation have been supplied in the case beforehand. What the players must do is rate 
the subjective importance to them of these issues (terms) and these actual values 
(options). This is seen in the two tables showing player Maki's ratings for the issue 1 
and issue 2 options. 

At this point since all the possible values (options) for the only two issues in this case 
are known, INSS also asks the players to evaluate packages — i.e. combinations of issues 
and cfptions, such as those Applicants' attorney has listed above in the aircraft model. 
Package 9 in that table is the same as the first package listed in the INSS article on page 
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9 for Nfaki-namcly issue 1 having an option of $320,000 and issue 2 having an option 

value of no warranty. Maki's rating of this package is 100. 

As INSS makes clear, me ratings by the players mustbe also be done before any mock 
negotiation can begin. 

The rejection of Applicants' claims suggests that INSS sends and receives terms along a 
communications path and that this is involved in the determination of Pareto- 
optimaUty. Applicants believe they have shown that in fact, neither party using INSS 
enter* issues, options or ratings durin g a mock negotiation. All possible issues and 
options were entered by the person who created the case beforehand. Thus INSS cajmQt 
identify which issues and options relate to which party, since there is no way for a 
person creating a case to indicate this and no way for the players to do so either. 

rNSS also does not analyze terms to understand which are significant to a Pareto- 
optimal outcome. By having the players rate the issues and options, the users or players 
specify the data (their subjective ratings) to be used for determining a ParetoK>ptimal 
outcome— not the INSS system. Applicants respectfully submit that Pareto-optimality 
sounds more complicated than it is. In this context, it simply means that based on the 
subjective ratings the players provide ahead of time for each predefined package, there 
coulii be one or more packages that are better for both players (have a higher subjective 
ijatirig for both players without making either player worse off) than the one they may 
initially choose. 
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Notelthat it is explicitly stated in INSS that this notion of "better" does not take into 
account any of the values supplied for the issues and options. It docs not matter what 
the issue 1 and issue 2 values actually are for the INSS system in the aircraft model 
exaifiple cited. All that matters for a Pareto-optimal result is that both players may have 
subjectively rated one or more packages as better than a package they have agreed 
upon;. 



this is made clear at Page 12, under the heading "Post-Settlement": 
"Effi&ont packages 

In some negotiations it may happen that the parties reach an agreement but there is (sic) 
one dir more packages which are better than the accepted offer for both sides. Note that 
fetters measured with the parties utility functions . Thus, there may be a packag e for 
which the two rating s are higher than the packag e that has been accepted. 

INS&has a post-settlement stage, during which it uses the preference information 
provided by each user to determine whether it is possible to construct packages that are 
betted for the two parties../' 
Utility function is defined in the glossary as: 

*:A Utility function is a subjective measurement that expresses th e relative value of 
different package (sicl by using a numerical scale. The numerical scale used is arbitrary. 
It typically ranges either from 0 to 1 or from 1 to 100. The minimum number expresses 
the feast desirable and least preferred package* The highest number represents the most 
desirable and preferred package. " lUnderlining emphasis added] 

In other words, the utility function INSS uses is simply the subjective ratings the players 
provide for the pre-defined packages. 



lit the aircraft model example above, if the parties had agreed upon Package 12 during 
the fftock negotiation, for which their subjective ratings are 60 and 10 respectively, it can 
be seen that Package 10 would be Pareto-optimally "better" for both of them because 
each of them has subjectively rated Package 10 higher than Package 12. As mentioned 
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above, these ratings are the player's subjective views of the importance of the issues 
(terms) and options (values). 



Thus, it is not necessary nor does INSS disclose or render obvious a need to understand 
the purpose of terms (issues) or values (options) in order to determine a Fareto-optimal 
package. It is done solely on the basis of subjective ratings supplied in advance for 
packages defined in advance. As described at Page 1 2, the determination of such an 
optima) package is not done during iterative processing of the mock negotiation, but 
alfter the conclusion of the mock negotiation. To determine if a package is Pareto- 
optiirial, all INSS has to do is compare the parties' ratings for the various packages to 
see if any package has higher ratings for both of them* If none of the packages have 
higher ratings for both parties, then the one they agreed on in the mock negotiation is 
Pareto-optimal for them. This is a simple arithmetic function and has nothing to do with 
analyzing the issues (terms) or options (values) in the mock negotiation. 

The Rejection of applicants' claims in view of INSS further states that INSS processing 
includes: 

"recognizing any changes in the terms ..." . 

Applicants respectfully disagree again. As applicants believe their above analysis 
shows, there are no changes in the terms to be detected or recognized by INSS. All 
possible term values (issues and options) are specified ahead of time, when the issues 
and options are specified so the case can be built. The players do not enter new issues or 
options during a mock negotiation, they select from packages or the predefined options 
to construct "offers". 

P*prt4f)of 55 

PAGE 39756 1 RCVD AT 5/5(2006 10:29:38 PM [Eastern Daylight Time] 1 SVR:USPT0-EFXRF-6I24 * DNIS:2738300 ' CSID:508 653 8143 * DURATION (mnws):15-50 



Sent By: MAUREEN STRETCH; 



508 653 8143 ; 



May-5-06 10:41PM; 



Page 40/56 



Docket Number ET00-001 CTP PATENTS 



This is:made clear at page 15, under the heading "3.Us'mg INSS", starting at number 6: 

"6; Rafe the packag es, A number of packages are displayed for you. Each package has a 
ra&ng;:Check if you agree with the ratings. If you disagree with the ratings of any of the 
packages change them in the box on the right-hand side of the table. Please do not try to 
manipulate these rankings as they are used for their own benefit. 

From now on every offer (a package) which you want to consider and present to your 
partner will show a rating based on your preferences. Any offers sent to you by your 
partner will also show a rating. Remember, this rating reflects your and only your 
opinion. Your partner does not know your opinion nor can he or she see your ratings. 

7. fill out the pre-negotiation questionnaire. 

8- Makfe an offer to your partner using the menus in the offer-box. You can also send 
messages to your partner using the message-box." [Bolding added] 

It appears from this that the players do not enter option values such as $310,000 in an 
offer screen during the mock negotiation. Instead, as the above excerpt from the INSS 
article says, the INSS simulator presents the players with a menu of the predefined 
packages, from which they select one — such as Package 12, for example, to use as an 
"offers 



Thus, ?tn "offer" of $310,000 and 0 warranty, is not a change in terms or a new term . It is 
one of the packages which was predefined when the case was set up initially. It is also a 
package which each of the players has already rated during the pre-negotiation rating 
phase. These ratings are presumably also stored in connection with the predefined 
packages. This is why it is a simple matter for the INSS system to "present" that offer to 
the othfer player, and along with it show to the other player that player's (Suny in this 
example) rating for that same predefined package. 
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For example, in the aircraft model for the airplane example, predefined Package 9 has a 
rating of 100 for Maki and a rating of 0 for Suny. If Maki "offers" package 9 to Suny, the 
INSS simulator does not have to recognize any changes in order to present Package 9 to 
Simy: There are no changes to Package 9. Nor does INSS have to do any calculation to 
show Sun/s pre-supplied rating of 0 for Package 9, as that value has also been 
previously stored. The rating Suny has previously supplied is not based on any changes 
initerlns (issues and options), since there can be no changes during a mock negotiation. 

INSS tfoes not have to plug in the correct data into any calculations, since all the data 
for issues, option values, and ratings has been entered before the mock negotiation 
began; Even the Pareto-optimal solution(s) for the players can be determined in 
advance using the ratings supplied by the players, INSS only needs to wait until after 
the mock negotiation has completed to suggest the better solutions. 

It is also a simple matter for INSS to "track" the mock negotiation without analyzing the 
issues pr options to understand their purpose or recognizing any changes in the issues 
or bpti&ns- All it has to do is record in a file that player 1 "offered" predefined 
package 3 at time x, then player 2 "counter-offered'' predefined package 4 at time y,. 
and soon. 

It is a simple matter to plot the graphs shown on Page 11, since the graphs are only 
showing the players' predefined ratings for the sequence of packages that were 
"offered". Since the ratings have already been supplied in advance of any mock 
negotiation, they can simply be stored in a table or model. The content of the packag es 
does not change during the mock negotiation. 
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This is quite clear from each graph. On the y axis or vertical side of the graph are shown 
the possible ratings, and on the x axis, or along the bottom of the graph are shown the 
d^tes when "offers" were exchanged. The two lines in each graph represent the "offers" 
from each party- The graph on the left shows the player Maki's (Misty's?} ratings for 
both sets. The graph on the right is different for the other player because it shows the 
sets of: "offers" as they were rated by that player. 

Since all of the "offers" which are rated and have their ratings graphed in the article 
were based on predefined packages, the graphs do not show anv changes in terms. 
because there is no way for a plaver to chang e terms during a mock negotiation . Maki's 
rating for Package 9 will always be 100, when that package is offered to Maki, no matter 
when it is offered. Similarly, Suny's rating for Package 9 will always be 0 when that 
package is offered to Suny, no matter when the package is offered. 

What the players are doing when they use the INSS simulator is presenting offers of 
predefined issue and option data, as described above. It should be noted that while the 
primary method INSS describes for selecting these predefined issues and options uses 
what it; calls parallel negotiations in which the players select from complete packages to 
present; an "offer", the INSS article describes on Page 3, an implementation of what it 
calls S^juential negotiations, in which the players can select from a subset of predefined 
issues and options, so that a complete package does not need to be selected. That 
presumably, is why the players are also asked to rate the issues and their options 
separately as well as the different packages- In any case, there are still no changes in 
tcrins, since all the issues and options and ratings must still be predefined before the 
mock negotiation can begin. 
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Afi important problem that has to be mentioned here is the approximation of the 
utility /The Utility function that is determined during the pre-negotiation phase has to be 
interpolated with new options being specified." 

[Emphasis added] 



While at first blush this might seem to suggest that a player can enter a new value 
during a mock negotiation, the last sentence makes it doubtful exactly what occurs. 

First, for continuous issues, a "new value" must be an intermediate value — i.e. in the 
range of the previously defined values. If it is not an intermediate value, then all the 
ratings would have to be redone, in a pre-negotiation step. Recall that in the discussion 
of ratings, for each option supplied for an issue, one must be given the maximum value 
and orte must be given a value of 0. Thus, if the ratings are to be useful at all, the only 
way a "new value" can be included for a continuous variable is if the new value is an 
intermediate value already in the range of the values which have been rated, This 
seems clear from the point made in the sentence "An important problem that has to be 
mentioned here is the approximation of the utility. The utility function that is 
detenMned during the pre-negotiation phase has to be interpolated with new options 
being specified " 

The utility function (rating) that has been supplied for this issue and its previous 
options; (values) has to be "interpolated" according to the above. Interpolation, as 
defined in Webster's New World dictionary, item 3 Math, means "to estimate (a 
missing functional value) by taking a weighed average of known functional values at 
ndghboring points, as in estimating a specific, missing intermediate value on a table, 
esp. a logarithmic or trigonometric table/' Thus, it would appear that the 1NSS 
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simulator or the NSS software would assign some rating to this intermediate value. 
However, it is not clear when that would be done — from the last sentence quoted it 
appears that this is done at the pre-negotiation phase. The article is ambiguous on this 
point. One way of reading this is that the interpolation might be done during a mock 
negotiation, but that is not what this appears to say. 

Apparently this feature, and the feature described as new values for discrete issues, 
would allow a user to modify an existing negotiation case. But apparently this would 
still ha?ve to be done before the mock negotiation occurs as the discussion of the impact 
on utility functions (ratings) makes clear and as the general discussion of the operation 
of INSS in constructing offers makes clear. This apparently is also the reason why a 
"new" continuous value must be an intermediate value (in the example shown, 
somewhere between 10 and 30), since that would also be the only way INSS could 
interpolate a rating for it. 

Ihe discussion of new discrete values makes it even clearer that the players must go 

back to the pre-negotiation stages to enter ratings, as is said at page 5: 

"Since there is no way to caculate {sic} the rating of new values based on the ratings of 
other options, the user would be required to enter the rating for any new discrete 
options/' 

Ratings can only be entered during the pre-negotiation phase. Because of the way in 
which INSS describes how a player selects an offer from pre-packaged sets, it seems 
logical to conclude that options 5 and 6 only allow' someone to modify an existing case 
before another mock negotiation begins. 
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To see this, it helps to understand how INSS works and its terminology. At INSS page 6, 

under the heading "Describe a new negotiation case", the article states: 

Spedlpthe 2 issues*** 3 negotiation case be U P for y° u b y submitting this form. 

At a iriirdmum you must specify the names of the issues that will be negotiated, and the 
options that each is.su* m ay t a w> For 0 y a ^pi^. * * U/ 102 

"Annjial salary" - "50,000", "70,000" or "100,000" dollars. 
"Vacation" - 2, 4 or 6 weeks." [Underlining emphasis added.J 

In the glossary of the INSS article on page 19, an issue is defined as: 



A topic of discussion that is of particular interest in a negotiation. Each issue has a 
range <*£ alternatives or options, one of which must ultimately be agreed upon by the 
negotiators in order to achieve a compromise." 

And at Page 20, an option is defined as: 

"One of the alternative values that an iggue^can take. For example, the issue 'Tolerable 
product failure rate" may have the options "3%", "5%" and "10%". 

In other words, an issue is similar to a term in a real negotiation. However, because this 
is a simulation using a simulation model or case, as seen here, all the possible values for 
an issue (term) must be defined in advanrp In this instance, these values are supplied 
as What INSS calls "options". As noted above, the article says that to create a new case 
vou must, at a minimum, specify the names of the issups that will be negotiated, and the 
options th at each issue may take . 

Again, on Page 8, under the headings "Using INSS: An Example", and "Negotiations 
between Maki and Suny", the article describes a sample negotiation case which has 
been set up by the article's authors to show how to use INSS: 
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This pre-definition is made even clearer on Page 17, where the INSS article states, under 

the heading "INSS FAQ (Frequently Asked Questions)", question no. 2: 

"2; I have requested a negotiation already. When can T start my negotiation? 
Your Negotiation will be set up typically within 2-3 days. INSS will notify you via e- 
mail, (specifying your negotiation name and user name), after which you can start your 
negotiation right away." 

The set up mentioned here refers back to Page 6, "Describe a new negotiation case, 
whereShe article states, "You can request that a new negotiation case be set up for you 
by submitting this form." 

Neither of the players who use the INSS simulator for a mock negotiation supply the 
values; (options) for the issues during their mock negotiations. These values have 
already been programmed into the case they are using before the mock negotiation 
begins. In fact unless one of the players is the one who requested that the case be 
constructed, neither of the players provides any input at all for "terms" (issues and 
their options) when he or she uses the INSS simulator. 

Page -8, for example, shows the aircraft case which has been set up by the authors to 
sWhow to use INSS. In this example, players "Maki" and "Suny" do not supply any 
of the options for issues 1 and 2. Since the "terms" (issues) and all possible values 
(options) they can have are pre-programmed into a case before a mock negotiation can 
begirt; there is no need for, and no disclosure of any analysis done by the INSS 
simulator to understand the purpose of the terms (issues). Unlike applicants' invention, 
which analyzes terms during iterations of a negotiation to understand their purpose, it 
is irrelevant to the INSS simulator whether an "issue" is a price term or a warranty term 
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Applicants believe that a few lines in the article create the confusion on this point. On 
Page 3 of the IN5S article, it states that INSS has a list of 9 options under the heading 
"Negotiation Protocol." The list is preceded by a paragraph which states that "At 
preseht INSS allows to construct a protocol from three options listed below/' In that 
list, Option 5 is "New values for continuous issues and Option 6 is New values for 
discrete and ordered issues and item 7 is New issues. 

Dfaectly below this, the article states under the heading "How to choose?'' : 

"Because the additional options listed above are not yet implemented you don't need to 
choose any specific protocol now. The three options already implemented provide you 
with Additional flexibility in conducting negotiations/ 7 

These seem to suggest that users might be able to enter new values for issues under 
optidiis 5 and 6, However, this also seems to say that only the first three options are 
implemented -not options 5, 6 and 7. However, even if they are deemed to have been 
implemented Applicants do not believe they change the above analysis. 

For example, in the discussion of " New values for continuous issues" the INSS article 
states: 

"This; option will allow to enter any value for a continuous issue other than the values 
specified at the beginning of negotiations. The continuues {sic} issue (sic) are those for 
which intermediate values make sense. Price, for example, is a continuous issue. The 
initial values may be $10, 420{sic) and $30. The option allows users to enter value {sic} 
of, for example, $15 which initialy {sic| had not been an option. 

Here We will also allow quasi-continuos jsic} issues which are naturally ordered but for 
which ratios or some other numbers make no sense. For example, such an issue is the 
proj^t completion time or product delivery time. Tt does not make sense to talk about 
delivery time of 1*75 days. However, we will leave this problem to the users and 
assume that they will select numbers that make sense in their negotiations. 
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Claims 2-17, 26-41, 50, 51, 60-70, 77-87, and 98 were rejected under §102 as being 
anticipated by the INSS article, and under §103, as being obvious in view of the INSS 
article. Claims 99-162 have been added. 

Anticipation under §102: 

The rejection stated that the fact that INSS maintains offer history data to determine if 
an optimal agreement has been reached or to suggest a Pareto-Optimal agreement for 
both parties is indicative of the fact that INSS itself analyzes and understands the 
negotiation terms. 

Applicants respectfully disagree. INSS is not a negotiations system, it is not analyzing 
terms during iterative proc«ssi ng to understand the purpose of the terms, it does not 
identify which terms relate to which party, it does not recognize changes in terms, and 
it does not recognize at least one party as a deciding entity. 

The INSS system does not do any analysis to understand the purpose of terms to 
generate a Pareto-optimal agreement for both parties, nor does it identify which terms 
and irijputs relate to which party and are significant to the Pareto-optimal analysis. The 
INSS article makes clear in discussing how to "Describe a new negotiation case", that all 
the terms and values for the mock negotiations are provided to the INSS system by 
whoever builds the case before any mock negotiation begins . As will be seen, this 
eliminates the need for any analysis of terms to understand their purpose, whether to 
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Similarly, option 7, New issues is described on Page 5 as: 
"New issues can be brought to the negotiation tabic during or even before the 
negotiation begins. This allows INSS users to make their own negotiation case online or 
extend greatly their current negotiation." The only description of how this might be 
implemented, if it was ever implemented, has already been covered above in the 
discussion of creating a new case. A new case can be created by predefining all the 
issues and options ahead of time, as described on page 6 of the INSS reference, the very 
next page after this discussion. 

Another paragraph in the article which seems to suggest more than it actually offers 

occursi on Page 2, under the heading "4. Negotiation support system": 

"INSScan also act as an NSS and support and facilitate real-life negotiations. The 
system 1 is designed so that two parries who can aereeon the issues and the possible 
o pKo^ for those issues can negotiate over the Web. This is an obvious advantage when 
the parties are widely separated and may have difficulty arranging meetings. Using 
iNSS is also helpful when post-settlement improvement is likely." [Underlining 
emphasis added.] 

Again; at first blush, this seems to offer more scope for INSS, but it is only helpful if the 
"two parties can agree on the issues and the possible options for those issues." In INSS 
terms; *his means the parties must create a new negotiation case which predefines all 
thb values for the issues and options, as discussed above. Those familiar with real life 
negotiations realize that it is unlikely that this will occur— most of a real world 
negotiation is about the value to be assigned to an issue as a negotiation progresses 
through a series of iterations. 

In any| case, if the parties were to agree to a predefined set of values for the issues and 
options, the INSS system would still only be able to provide NSS support— that is, 
perform the Pareto-optimal determination based on the parties' ratings and perhaps 
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suggest better packages. This might be helpful but it is not a negotiations system. It is 
usihg a: simulator for providing a negotiation support system function, not analyzing 
terms to understand their purpose or recognizing changes in terms. The authors of the 
INSS article clearly recognize this when they preface this discussion by saying that 1NSS 
car* actas an NSS and su pport and facilitate (but not process) real-life negotiations. 

While it might be argued that simulators may sometimes anticipate functionality for 
purposes of patentability, applicants submit that in computer hardware and software 
development, simulation tools have long been used to feign functionality that is still 
uruier development. If a manufacturer is developing a new operating system and new 
coinpiiter hardware at the same time, it is common for developers to use simulation 
tools tb mimic functionality yet to be developed. The real operating system may be 
interfaced to a simulation model that pretends to operate as the hardware should, even 
if the jiardware developers do not yet know how to implement the hardware. The 
operating system may pass a value to the simulation tool, which "pretends" to operate 
on it, b>t simply returns to the operating system a pre-programmed answer for that 
value; The simulation tool could be said to be performing the same functionality as the 
as yet undeveloped hardware, without necessarily anticipating the later hardware 
features actually developed. 

Iri any event, applicants respectfully submit that it has now been shown that INSS does 
not perform the same functionality recited in Applicants' claimed invention and does 
not anticipate, disclose, teach, nor render obvious Applicants' invention. The authors of 
the INSS paper do not describe it as a negotiation system. They are quite clear that it can 
be used as a game, a demonstration decision support system, a negotiation simulator, a 
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demcrnstration negotiation support system or a research and training tool but they do 
not disclose or describe it as a negotiation system. 

The descriptions of How to create a case in order to use the simulator make it clear that 
all" the possible values and issues must be identified, specified, and predefined before a 
negotiation can be simulated. Since all the issues and options are defined in advance, 
the DMSS software does not analyze terms to understand their purpose, nor does it 
recognizes changes in terms. It can only deal with pre-programmed issues and options. 

Trie description on Page 15 of how "offers " are constructed from the predefined, pre- 
rated packages, makes it clear that the players do not change any terms (issues and 
options) during their mock negotiation. They "offer" the predefined packages or 
subsets of them to each other until they reach an "agreement" in their mock negotiation. 
Since there are no changes in the terms during such a mock negotiation, the INSS 
system cannot recognize changes. 

The rejection also stated that, INSS recognises which party is officially waiting for a 
response, thereby recognizing a relative 'deciding entity/ See page 17, it*?m 5 in 
particular." 

Applicants respectfully disagree. First, applicants can find no instance in the article 
whicK states that INSS recognizes which party is officially waiting for a response. 

In fact, it would seem that the opposite is true the INSS system is indifferent to which 

party to a mock negotiation is "officially" waiting for a response. At Page, 14, under 
the heading "1. Introduction" it states: 
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None of these suggests that ENTSS recognizes either player as "officially" waiting for a 
res^ruU. Instead, because these cites suggest that either party can send multiple offers 
to the other without receiving any response, it is clear that there is no "officio!" waiting 
for; response status that would suggest INSS recognizes the one waiting as a relative 
deciding entity. Nor does the abUity to send multiple offers make either party a P 

m 

deciding entity. 

o 

Applicants respectfully submit that INSS does not recognize either player as a deciding ^} 
enkty;>ut, on the contrary, as is stated on Page 16, it would appear that the INSS ^ 
simulator and NSS functions determine when negotiations are concluded: 
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"11. When both you and yotxr partner accept on offer, it i s» era Herd an lagreexnenti . (sic) 
INSS >vill tell you whether your agreement is "op t_Li lAal", or whether i t i i* pot*i*ible to 
improve it and move towaros a. better agreement." 

12. If INSS <i~»y a you have re ached the end of negotiation, fill out the pc>»t-nesotiatlort 
questionnaire. Otherwise you H a ve the choice of rnalcLng more offers till you reoch a 
bettor agreement or stopping at thia poi nt. In any case fill out the que«tionnairc when 
you reach the end of the negotiation." ["Holding emphasis nddedj 

From this, it would seem that neither party is a deciding entity. "The INSS simulator 
decides whether a negotiation ended. 

In summary, ITsJSS as disclosed and described in the article cited does not*- in any way, 
perfonn the functionality of Applicants' claimed i n vention, nor would, it render it 
obvious. IhJSS is not a negotiations system . INSS does not analyze terms to understand 
their purpose, nor does it recognize changes In terms, nor does it recognize a party aft a 
deciding entity. Tn fact to the extent that INSS requires predeflnition of values it 
teaches away from Applicants' invention and relates to older art on (simulation tools 
and decision theory, not to Applicants' invention . Oonseouently, Applicants 
respectfully submit that this basis for- rejection has been o v «rco m e and that Qaims 2—3.7, 
26-41,50/ 31, 60-70, 77-37, and as well as ne-w claims 99-162 are in condition for 
Allowance. 

Obviousness under Q103: The rejection states that the u£»e of unique identifiers, and 
maintaining records as an audit function would be obvious to one of ordf nary olcill in 
the art, and would not, by themselves, -render the claims patentable in view of INtiSii. 
Applicants respectfully submit that this is a moot point since the rejection based on §102 
has been overcome- Consequently, Applicants respectfully submit that this* bat* it* for 
rejection' has been overcome and that Qaims 2-17, 26-41,50, 51, 60-70, 77-87, and 98 as 
well as new claims 99-162 are in condition for AJlowance- 
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and again at CZoI - 2-4:, lines 45-58: 

While some users of the present invention may want to install parts of it locally, it -if? 
another advantage of the present Invention that it can also be used for a "one-time'" or 
"nearly; inatantaneous" c ommunity negotiation. Turning briefly to Figure lc, if the 
spctfidor of community «CI3 is a standards body, it could create a community Website for 
thfc? negotiation of a porrlculor ^ nda rd. enlist participants, and encourage and monitor 
the; negotiations without anyone having to buy or install additional local hardware or 
software. When the negotiation Is complete and the concluding agreed upon standards 
document can be made avail able to all concerned, the com m unity could bo 
"dismantled"" and the participants could disband without wasting any hard-ware or 
wftware installations and expenses. [Emphasis added] 



and again at Col. 27, lines 43-64: 

In this diagram, It is assumed that a seller ia regiaterine for the first time witli a 
sponsored commerce community. Other types of communities might vary this 
processing. First, at step 400. the seller chooses from one or more templates provided by 
multivariate negotiations engine system 02. based on the level of cost and functional! ty 
the. seller desires. Sample website pages constructed from such templates by a 
hypothetical company named Exports, Inc., are shown in Figures 31a to 31 d. 



r^Ieict* at step 405 in Figure 4a the seller provides basic information as* preempted by the 
system: through a setup screen such as that shown in Figures 10-1-10-3. for Lions of -the 
demographic information collected there, along with other data collected later is 
automatically formatted along with the META tags and Ivleta Keywords for automatic 
submission to search engines. A.t step 410 in Figure 4a, th e system presents the? 
cornrnuhirv^s F^tand^rd license atyreernenr and term« to the seller. If the seller agrees to 
the terms at decision block425, processing continues. If the seller does nor ayrce. the 
f^Ucr may proceed to bjocK to nerflOtifltfT w>tb yponsor Qr e^ect; not to IP fUTUgir^ftf,^- 

[Emphaeis added] 



rn 
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and; at Col - 15, lines 7-12: 
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and access level s for each inquirer [Emphaflis added] 



O 
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and;' again at Col. 23, lines 24-41; 

Stall* in Figure Id, the principal functions of the present invention operate a» port of 
Webserver software 210s executing in Webserver hardware 210w. Multivariate 
negotiations engine 212 is the central function, with sponsor functions 213, participant 
functions 214, external functions 211 and network functions 207 working in cooperation 
with It. All of theee. in Kirn, communicate through j-he UP* firewall 2Q3f. to database 
functions 222 , operating with database uerver system 22Q, to maintain databane(s) 225. 
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Security of sponsor and participants' communications is provided at the Webserver 
level flirough secured socket laver (S SL) encryption schemes offered by most Webserver 
software products, while an a dditional layer of security is provided by restricting access 
to database server comp uters 230, where databases 225 resides, bv use of IP firewall 
203f , Thus, the pre sent invention enables the collection and storing of negotiations and 
results data in a high ly secure hosting: environment over a public network 

Consequently, Applicants respectfully submit that the instant application be granted 
the priority date claimed. 

Applicants respectfully submit that all bases for rejection have been overcome, that the 
instant-application should be granted the priority date claimed and that Claims 2-17, 26- 
41,50, 51, 60-70, 77-87, and 98 as well as new claims 99-162 are in condition for 
allowance. Reconsideration of all the claims is requested. Allowance of Claims 2-17, 26- 
41,50, Si, 60-70, 77-87, and 98 as well as new claims 99-162 at an early date is solicited* 

Applicants ' Attorney respectfully requests that if she can be of any further assistance in 
putting all the claims in condition for allowance that she be reached by telephone at 
508-65^-8143 in order to discuss the application with the Examiner, so that any new 
objections or rejections may be addressed. 

Respectfully submitted, 

Maureen Stretch 
Reg. N0. .29,447 
26 Charles Street 
Nafidv MA 01760 
5/5/2006 
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"Pjartieipants in the negotiation are paired randomly and anonymously. Your partner 
may t>6 from your city, country or from far away: a different country, a different 
continent. Please log in at lest once in two days to check whether there has been any 
activity. If you have provided an e-mail address, INSS will send you a note when your 
counterpart makes an offer, but it is better not to rely on these e-mails; do log in 
frequently/' * 

Also, oh Page 15, under the heading "3. Using INSS", it states: 

"8/Make an offer to your partner using the menus in the offer-box. You can also send 
messages to your partner using the message-box. 

9. You will then have to wait for your partner to respond to your offer. Come back later 
(say the next day) and login to INSS using the same negotiation name, user-name and 
pa&wpn± INSS will show you whether your partner has sent you a response. Keep 
checkiiig till you get a response. Tf you like, you can continue to send messages or new 
offers to your partner ." [Underlining emphasis added] 

And the section cited in the rejection at Page 17, item 5 reads: 

"5. 1 hiVe sent an offer and my counterpart has not yet responded to it INSS shows 
me: a "Waiting for response" page. Can I send a second offer instead of waiting? 

Yes, you can make consecutive offers without waiting for your counterpart. Click on the 
"MakeJ^n offer" link in the menubar at the bottom of your page. There is also a link in 
themeriubar that allows you to just "Send a message" instead of an offer ♦" 

None of these suggests that INSS recognizes either player as ''officially" waiting for a 
response. Instead, because these cites suggest that either party can send multiple offers 
to the other without receiving any response, it is clear that there is no "official" waiting 
for respbnse status that would suggest INSS recognizes the one waiting as a relative 
deciding entity. Nor does the ability to send multiple offers make either party a 
deciding entity. 



Applicants respectfully submit that INSS does not recognize either player as a deciding 
entity, but on the contrary, as is stated on Page 16, it would appear that the INSS 
simulator and NSS functions determine when negotiations are concluded: 
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The Examiner rejected applicants' priority claim for the instant application, because the 
ph*?asesj "dynamic contracts manager" and "security extensions such as access control 
lists, privilege lists, etc/' were not disclosed in the parent applications, such as US 
Patent No. 6,141,653. 

Applicants respectfully disagree. As this application claims, the dynamic contracts 
manager supplies an initial set of terms for use by a user. As stated in the instant 
application at Page 79, this functionality operates in conjunction with the sponsored 
commimity function of the parent applications. 

Applicants respectfully submit that support for this functionality is found in the above 
referenced parent application at Col. 17, lines 46-47: 

The sponsoring standards body establishes the community, proposes initial standards, 
sets thej rules for negotiations, encourages and monitors negotiations, and concludes 
with a finally agreed upon set of standards, with each step of each negotiation that 
occurred along the way archived. [Emphasis added] 

and again at Col. 20, lines 6-18; 

In a commerce community, the participants might be grouped as sellers OSgrpa and 
buyersb8grpb. Seller participant 08grpa functions include automatically integrated 
remoteJWeb authoring 214-02 and processing and administration 214-04. In remote 
Web authoring 214-02^ the present invention allows a seller registering with the 
sponsoted community, to automatically create a seller's Website within the community, 
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on completion of registration. The seller selects from several Website format templates 
provided bv the present invention and as the seller "fills in the blanks" in a selected 
template, the information is automatically integrated with the rest of the system, so that 
orders ton be processed and accepted immediately ...F Emphasis added] 

and again at Col. 23, lines 61-67: 

In hon commercial communities, such as standards communities or treaty negotiation 
communities, a sponsor 06 may wish to designate multiple deciding entities for each 
issue uiider consideration. In such an implementation, a sponsor 06 will usually want to 
establish m ore detaile d rules for th e ordering and processing of proposals. (Emphasis 
added] :• 

and again at Col. 24, lines 45-58: 

While some users of the present invention may want to install parts of it locally, it is 
anotheir advantage of the present invention that it can also be used for a "one-time" or 
"nearly -instantaneous" community negotiation. Turning briefly to Figure lc, if the 
sponsor of community CB is a standards body, it could create a community Website for 
tne jnegbtiation of a particular standard, enlist participants, and encourage and monitor 
the negotiations without anyone having to buy or install additional local hardware or 
sof twat£. When the negotiation is complete and the concluding agreed upon standards 
document can be made available to all concerned, the community could be 
"dismantled" and the participants could disband without wasting any hardware or 
software installations and expenses. [Emphasis addedl 



and again at CoK 27, lines 43-64; 

In this diagram, it is assumed that a seller is registering for the first time with a 
spojnsoifoA commerce community . Other types of communities might vary this 
processing. First, at step 400, the seller chooses from one or more templates provided by 
multivariate negotiations engine system 02, based on the level of cost and functionality 
thejsel&r desires. Sample website pages constructed from such templates by a 
hypothetical company named Exports, Inc, are shown in Figures 31a to 3ld, 

Next, at step 405 in Figure 4a the seller provides basic information as prompted by the 
system; through a setup screen such as that shown in Figures 10-1-10-3- Portions of the 
detfiogtfaphic information collected there, along with other data collected later is 
automatically formatted along with the MET A tags and Meta Keywords for automatic 
submission to search engines. At step 410 in Figure 4a, the system presents the 
coa^&it/s standard license agreement and terms to the seller . If the seller agrees to 
theiterms at decision block 425, processing continues. If the seller does not agree, the 
seller gray proceed to block 420 to negotiate with sponsor or elect not to participate . 
[Emphasis added] 

and at Col. 15, lines 7-12: 

Pa^pWof 5.5 
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